Amazon CloudWatch Observability アドオンを利用して SageMaker HyperPod を監視してみた

Amazon CloudWatch Observability アドオンを利用して SageMaker HyperPod を監視してみた

Clock Icon2025.01.07

こんにちは!クラウド事業本部コンサルティング部のたかくに(@takakuni_)です。

SageMaker HyperPod はいくつかオブザバビリティツールと統合しており、 CPU/GPU 使用率をはじめとした監視機能をシームレスに利用できます。

今回は Amazon CloudWatch Observability アドオンを利用して SageMaker HyperPod の監視してみたいと思います。

CloudWatch Observability アドオン

CloudWatch Observability アドオンは EKS ノードのメトリクス監視ツールです。

アドオンをインストールすることで、Fluent Bit, CloudWatch Agent をクラスター内にセットでインストールできます。

https://dev.classmethod.jp/articles/eks-on-ec2-container-insights-with-enhanced-observability/

CloudWatch Observability アドオンは Container Insights とも統合しており、強化されたオブザバビリティメトリクスにより、 NVIDIA, AWS Traininum などの GPU 、EFA など HPC 領域のメトリクスも収集できるポイントが強みです。

また、SageMaker HyperPod のノード用にアラートに利用できそうなメトリクスもいくつか用意されています。詳しいメトリクスの内容は以下をご覧ください。

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-enhanced-EKS.html

やってみる

今回は CloudWatch Observability アドオンを SageMaker HyperPod クラスター用の EKS クラスターにインストールしどのようなメトリクスが監視できるのか、ダッシュボードを眺めてみたいと思います。

IAM ポリシーのアタッチ

EKS アドオンをインストールする前に CloudWatchAgentServerPolicy をインスタンスグループの IAM ロールにアタッチします。

通常の EKS の場合、 IRSA を利用する方法またはワーカーノードの IAM ロールに CloudWatchAgentServerPolicy をアタッチする方法のどちらかを選択できますが、 SageMaker HyperPod の場合は IAM ロールに CloudWatchAgentServerPolicy をアタッチする方法になります。

Attach the CloudWatchAgentServerPolicy IAM policy to your worker nodes. To do so, enter the following command. Replace my-worker-node-role with the IAM role used by your Kubernetes worker nodes.

https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-eks-operate-console-ui-governance-setup-dashboard.html#hp-eks-dashboard-prerequisites

私は Terraform でやったのですが、以下のようになりました。

###################################################
# IAM Role for SageMaker HyperPod Cluster
###################################################
resource "aws_iam_role" "hyperpod" {
  name = "${local.prefix}-hyperpod-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Principal = {
          Service = "sagemaker.amazonaws.com"
        },
        Action = "sts:AssumeRole"
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "hyperpod_managed" {
  role       = aws_iam_role.hyperpod.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSageMakerClusterInstanceRolePolicy"
}

resource "aws_iam_role_policy_attachment" "hyperpod_observability" {
  role       = aws_iam_role.hyperpod.name
  policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
}

data "aws_iam_policy_document" "hyperpod_vpc" {
  statement {
    effect = "Allow"
    actions = [
      "ec2:AssignPrivateIpAddresses",
      "ec2:CreateNetworkInterface",
      "ec2:CreateNetworkInterfacePermission",
      "ec2:DeleteNetworkInterface",
      "ec2:DeleteNetworkInterfacePermission",
      "ec2:DescribeNetworkInterfaces",
      "ec2:DescribeVpcs",
      "ec2:DescribeDhcpOptions",
      "ec2:DescribeSubnets",
      "ec2:DescribeSecurityGroups",
      "ec2:DetachNetworkInterface",
      "ec2:ModifyNetworkInterfaceAttribute",
      "ec2:UnassignPrivateIpAddresses",
      "ecr:BatchGetImage",
      "ecr:GetAuthorizationToken",
      "ecr:GetDownloadUrlForLayer",
      "eks-auth:AssumeRoleForPodIdentity"
    ]
    resources = ["*"]
  }

  statement {
    effect = "Allow"
    actions = [
      "ec2:CreateTags",
    ]
    resources = ["arn:aws:ec2:*:*:network-interface/*"]
  }
}

resource "aws_iam_policy" "hyperpod_vpc" {
  name        = "${local.prefix}-vpc-policy"
  description = "IAM policy for SageMaker HyperPod VPC"
  policy      = data.aws_iam_policy_document.hyperpod_vpc.json
}

アドオンのインストール

それでは、アドオンをインストールしましょう、 IAM ポリシーがセットアップできていれば他に気にすることはないです。とてもシンプルで良いですよね。

aws eks create-addon --cluster-name cluster-name
--addon-name amazon-cloudwatch-observability
--configuration-values "configuration json"

configuration json は以下を設定しました。

{
	"agent": {
		"config": {
			"logs": {
				"metrics_collected": {
					"kubernetes": {
						"kueue_container_insights": true,
						"enhanced_container_insights": true
					},
					"application_signals": {}
				}
			},
			"traces": {
				"traces_collected": {
					"application_signals": {}
				}
			}
		}
	}
}

Terraform だと次のようになります。

resource "aws_eks_addon" "amazon_cloudwatch_observability" {
  cluster_name                = aws_eks_cluster.this.name
  addon_name                  = "amazon-cloudwatch-observability"
  resolve_conflicts_on_create = "OVERWRITE"
  configuration_values = jsonencode({
    agent = {
      config = {
        logs = {
          metrics_collected = {
            kubernetes = {
              kueue_container_insights    = true
              enhanced_container_insights = true
            }
            application_signals = {}
          }
        }
        traces = {
          traces_collected = {
            application_signals = {}
          }
        }
      }
    }
  })

  depends_on = [
    awscc_sagemaker_cluster.this,
  ]
}

負荷掛け

GPU はお高いので、今回 worker-group には m5.2xlarge(8vCPU, 32 GB メモリ)の CPU インスタンスを 2 台使用しました。stress コマンドで負荷がけしてみました。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cpu-memory-stress-deployment
  labels:
    app: cpu-memory-stress
spec:
  replicas: 2 # Podのレプリカ数を1に設定
  selector:
    matchLabels:
      app: cpu-memory-stress
  template:
    metadata:
      labels:
        app: cpu-memory-stress
    spec:
      containers:
        - name: cpu-memory-stress-container
          image: polinux/stress # stressツールを含む軽量なイメージ
          command: ['stress'] # 実行するコマンドを明示的に指定
          args:
            - '--cpu'
            - '4' # 4つのスレッドでCPUを負荷
            - '--vm'
            - '7' # 7つのスレッドでメモリを負荷
            - '--vm-bytes'
            - '4G' # 各スレッドが4 GiBのメモリを確保(合計28 GiB)
            - '--timeout'
            - '600s' # 600秒間(10分間)負荷をかける
          resources:
            requests:
              cpu: '4' # 最低限必要なCPUリソース(4 vCPU)
              memory: '28Gi' # メモリリクエスト
            limits:
              cpu: '4' # 最大4 vCPUを使用
              memory: '28Gi' # メモリ制限

ダッシュボードを確認する

1 時間ほど立ち上げたため、ダッシュボードを確認してきます。

HyperPod

HyperPod クラスターを開くと一発目にダッシュボードとして使用率が可視化できるようになっていました。また、インスタンスグループ別に GPU/CPU 数、利用率をフィルタリングできそうです。

2025-01-07 at 23.33.51-Amazon SageMaker AI  us-west-2.png

後日ブログにしますが HyperPod タスクガバナンスとも統合しており、チームごとにコンピュートの利用率を見られるようになるみたいです。

image.png
新しい Amazon SageMaker HyperPod タスクガバナンスを使用して、モデル開発のためにアクセラレーターの使用率を最大化より引用

私の場合、タスクガバナンスは利用していなかったため、インストール画面のみとなっていました。

2025-01-07 at 23.35.29-Amazon SageMaker AI  us-west-2.png

Container Insights

右上に「コンテナインサイトでの監視」とクリックできるボタンがあったため踏んでみます。

2025-01-07 at 23.38.41-Amazon SageMaker AI  us-west-2.png

Container Insights に遷移するとクラスターや名前空間別にメトリクスを可視化できるようになっています。

また、赤枠の部分は HyperPod ならではの部分ですね。

左下の HyperPod ノードのみは EKS クラスターに複数ノードが相乗りしている時に使えそうです。

2025-01-07 at 23.40.08-EKSCluster  Container Insights  CloudWatch  us-west-2.png

HyperPod ノードのステータスの info ボタンをクリックするとメトリクスの名前が出てきました。ラベルによってメトリクス出すのおもしろいですね。

2025-01-07 at 23.42.28-EKSCluster  Container Insights  CloudWatch  us-west-2.png

自動ノード復旧は発生するものの、 hyperpod_node_health_status_unschedulable hyperpod_node_health_status_unschedulable_pending_replacement などは監視項目にしてもいいかもしれません。

まとめ

以上、さらっとですが「Amazon CloudWatch Observability アドオンを利用して SageMaker HyperPod の監視してみた」でした。

今回は見られなかったですが、Container Insights が拡張されたことによる GPU 利用率の監視はかなりみたい部分にフォーカスできていて良い機能なのではないかと思いました。

セットアップも非常にシンプルですぐに導入できそうな印象を受けました。

このブログがどなたかの参考になれば幸いです。クラウド事業本部コンサルティング部のたかくに(@takakuni_)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.